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Abstract. We present a novel proof by induction algorithm, which 
combines A:-induction with invariants to model check C programs with 
bounded and unbounded loops. The fc-induction algorithm consists of 
three cases: in the base case, we aim to hnd a counterexample with up 
to k loop unwindings; in the forward condition, we check whether loops 
have been fully unrolled and that the safety property P holds in all states 
reachable within k unwindings; and in the inductive step, we check that 
whenever P holds for k unwindings, it also holds after the next unwinding 
of the system. For each step of the fc-induction algorithm, we infer invari¬ 
ants using afRne constraints (i.e., polyhedral) to specify pre- and post¬ 
conditions. The algorithm was implemented in two different ways, with 
and without invariants using polyhedral, and the results were compared. 
Experimental results show that both forms can handle a wide variety of 
safety properties; however, the k-induction algorithm adopting polyhe¬ 
dral solves more verification tasks, which demonstrate an improvement 
of the induction algorithm effectiveness. 


1 Introduction 

The Bounded Model Checking (BMC) techniques based on Boolean Satisfiability 
(SAT) [T] or Satisfiability Module Theories (SMT) are successfully applied 
to verify single- and multi-threaded programs and to find subtle bugs in real 
programs mm- The idea behind the BMC techniques is to check the negation 
of a given property at a given depth, i.e., given a transition system M, a property 
(j), and a limit of iterations k, BMC unfolds the system k times and converts it 
into a Verification Condition (VC) tp such that tp is satisfiable if and only if (p 
has a counterexample of depth less than or equal to k. 

Typically, BMC techniques are only able to falsify properties up to a given 
depth k; however, they are not able to prove the correctness of the system, unless 
an upper bound of k is known, i.e., a bound that unfolds all loops and recursive 
functions to their maximum iteration. In particular, BMC techniques limit the 
size of data structures (e.g., arrays) and the number of loop iterations to a given 
bound k. This also limits the state space that needs to be explored in software 
verification and has allowed BMC tools to find real errors in applications mw\, 
but at the same time it has also made them susceptible to producing time-out 
or memory-out for programs that contain unbounded loops or programs where 
the number of loop unwindings cannot be determined statically. 

Consider for example the simplistic program on the left of Fig. [^in which the 
loop in line 2 runs an unknown number of times, depending on the initial value 
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non-deterministically assigned to x in line 1. However, the assertion in line 3 
holds independent of x’s initial value. Unfortunately, BMC tools like CBMC 
[3], LLBMC [2], or ESBMC [S] typically fail to verify programs that contain 
such loops. They insert a so-called unwinding assertion at the end of the loop, 
which consists of the negated loop bound. This enforces BMC tools to choose 
an unwind bound sufficiently large to search deeper in the state space of the 
program, but with the drawback of exhausting time and memory resources. 


1 unsigned int x = *; 

2 while (x>0) X-; 

3 assert (x ==0); 


1 nnsigned int x = *; 

2 if (x>0) > 

3 X ; ^ k copies 

4 . . . J 

5 assert(!(x >0)); 

6 assert (x ==0); 


Fig. 1: Unbounded loop (left) and finite unwinding (right) 

One technique typically used to prove properties, for any given depth, is 
mathematical induction. The algorithm called fc-induction was successfully ap¬ 
plied to ensure that (restricted) C programs do not contain data races |7I8) and 
to respect time constraints specihed during the design phase of a system [9]. 
Additionally, the A:-induction is a well-established technique in hardware verih- 
cation, where it is easier to be applied due to the monolithic transition relation 
present in hardware designs [3]. This paper contributes with a new algorithm 
to prove correctness of C programs by mathematical induction in a completely 
automatic way (i.e., the user does not need to provide the loop invariant). 

The main idea of the algorithm is to use an iterative deepening approach 
and check, for each step fc up to a maximum value, three different cases called 
here as base case, forward condition, and inductive step. Intuitively, in the base 
case, we intend to find a counterexample of (j) with up to k iterations of the 
loop. The forward condition checks whether loops have been fully unrolled and 
the validity of the property (p in all states reachable within k iterations. The 
inductive step verifies that if (j) is valid for k iterations, then (j) will also be valid 
for the next unfolding of the system. For each step of the algorithm, we infer 
program invariants using affine constraints to prune the state space exploration 
and to strength the induction hypothesis. 

These algorithms were all implemented in the Efficient SMT-based Context- 
Bounded Model Checker tool (known as ESBMCp]), which uses BMC techniques 
and SMT solvers (e.g., |10lll| l to verify embedded systems written in C/C-|—I- [5]. 
In Cordeiro et al. [5] the ESBMC tool is presented, which describes how the 
input program is encoded in SMT; what the strategies for unrolling loops are; 
what are the transformations/optimizations that are important for performance; 
what are the benefits of using an SMT solver instead of a SAT solver; and 
how counterexamples to falsify properties are reconstructed. Here we extend 
our previous work and focus our contribution on the combination of the k- 
induction algorithm with invariants. First, we describe the details of an accurate 
translation that extends ESBMC to prove the correctness of a given (safety) 


^ Available at http://esbmc.org/ 
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property for any depth without manual annotations of loops invariants. Second, 
we adopt program invariants (using polyhedral) in the ^-induction algorithm, 
to speedup the verification time and to improve the quality of the results by 
solving more verification tasks in less time. Third, we show that our present 
implementation is applicable to a broader range of verification tasks, where other 
existing approaches are unable to support mm- 

2 Induction-based Verification of C Programs using 
Invariants 

The transformations in each step of the /^-induction algorithm take place in the 
intermediate representation level, after converting the C program into a GOTO- 
program, which simplifies the representation and handles the unrolling of the 
loops and the elimination of recursive functions. 


2.1 The Proposed fc-Induction Algorithm 

Figure shows an overview of the proposed fc-induction algorithm. We do not 
add additional details about the transformations on each step of the algorithm; 
we keep it simple and describe the details in the next subsections so that one 
can have a big picture of the proposed method. The input of the algorithm is a 
C program P together with the safety property (j). The algorithm returns true 
(if there is no path that violates the safety property), false (if there exists a 
path that violates the safety property), and unknown (if it does not succeed in 
computing an answer true or false). 

In the base case, the algorithm tries to find a counterexample up to a maxi¬ 
mum number of iterations k. In the forward condition, global correctness of the 
loop w.r.t. the property is shown for the case that the loop iterates at most k 
times; and in the inductive step, the algorithm checks that, if the property is 
valid in k iterations, then it must be valid for the next iterations. The algorithm 
runs up to a maximum number of iterations and only increases the value of k if 
it can not falsify the property during the base case. 


Differences to other fc-Iduction Algorithms Our fc-induction algorithm is 
slightly different than those presented by Grofie et al. [H], Donaldson et al. [7], 
and Hagen et al. m- In Grofie et ah, the forward condition and the inductive 
step are computed differently from our approach (as described in Section 2.1) and 
the value of k is increased only at the end of the algorithm; in this particular case, 
computational resources are thus wasted since loops are usually unfolded at least 
two times. Donaldson et al. [7] and Hagen et al. m propose the fc-induction with 
two steps only (i.e., the base case and the inductive step); however, the inductive 
step of the approach proposed by Donaldson et al. requires annotations in the 
code to introduce loops invariants, but our method is completely automatic as 
in Hagen et al [16] . Additionally, as observed in the experimental evaluation (see 
Section]^, the use of the forward condition, in our proposed method, improves 
significantly the quality of the results, because some programs that are hard to 
be proved by the inductive step can be proved by the forward condition using 
affine constraints. 





4 


Herbert Rocha, Hussama Ismail, Lucas Cordeiro, and Raimundo Barreto 


1 

2 

3 

4 

5 

6 

7 

8 
9 

10 

11 

12 

13 

14 

15 

16 
17 
IS 
19 


input: program P and safety property (f> 
output: true , false , or unknown 
k = 1 

while k <= max_iterations do 
if base_case(P, cj), k) then 
show counterexample s[0..k] 
return false 
else 
k=k+l 

if forward_condition (P, rj), k) then 
return true 
else 

if inductive_step (P, 4>, k) then 
return true 
end—if 
end—if 
end—if 
end—while 
return unknown 


Fig. 2: An overview of the ^-induction algorithm. 


Loop-free Programs In the fc-induction algorithm, the loop unwinding of the 
program is done incrementally from one to max-iterations (cf. Fig.j^, where the 
number of unwindings is measured by counting the number of backjumps | 15 j . 
On each step of the fc-induction algorithm, an instance of the program that 
contains fc copies of the loop body corresponds to checking a loop-free program, 
which uses only ^/-statements in order to prevent its execution in the case that 
the loop ends before fc iterations. 

Definition 1 (Loop-free Program) A loop-free program is represented by a 
straight-line program (without loops) by providing anite{ 9 , pi, P2) operator, which 
takes a Boolean formula 6 and, depending on its value, selects either the second 
Pi or the third argument p2, where p\ represents the loop body and p2 repre¬ 
sents either another ite operator, which encodes a k-copy of the loop body, or an 
assertion/assume statement. 

Therefore, each step of our fc-induction algorithm transforms a program with 
loops into a loop-free program, such that correctness of the loop-free program 
implies correctness of the program with loops. 

If the program consists of multiple and possibly nested loops, we simply set 
the number of loop unwindings globally, that is, for all loops in the program 
and apply these aforementioned translations recursively. Note, however, that 
each case of the fc-induction algorithm performs different transformations at the 
end of the loop: either to find bugs (base case) or to prove that enough loop 
unwindings have been done (forward condition). 
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Program Translations In terms of program translations, which are all done 
completely automatic by our proposed method, the base case simply inserts an 
unwinding assumption, to the respective loop-free program P', consisting of the 
termination condition a after the loop, as follows I AT A a ^ (f>, where / is the 
initial condition, T is the transition relation of P', and ^ is a safety property to 
be checked. 

The forward case inserts an unwinding assertion instead of an assumption 
after the loop, as follows I AT ^ a A (j>. The forward condition, proposed by 
GroBe et al. [T3], introduces a sequence of commands to check whether there is 
a path between an initial state and the current state k, while in the algorithm 
proposed in this paper, an assertion (i.e., the loop invariant) is automatically 
inserted by our algorithm, without the user’s intervention, at the end of the loop 
to check whether all states are reached in k steps. Our base case and forward 
condition translations can easily be implemented on top of plain BMC. 

However, for the inductive step of the algorithm, several transformations are 
carried out. In particular, the loop while{c) {E; } is converted into 


A] while{c) E;U]} R] 


( 1 ) 


where A is the code responsible for assigning non-deterministic values to all loops 
variables, i.e., the state is havocked before the loop, c is the halt condition of 
the loop while, S is the code to store the current state of the program variables 
before executing the statements of E, E is the actual code inside the loop while, 
U is the code to update all program variables with local values after executing 
E, and R is the code to remove redundant states. 

Definition 2 (Loop Variable) A loop variable is a variable v C V, where 
V = Vgiobai u Viocai given that Vgiobai is the set of global variables and Viocai is 
the set of local variables that occur in the loop of a program. 

Definition 3 (Havoc Loop Variable) Nondeterministic value is assigned to 
a loop variable v if and only if v is used in the loop termination condition a, in 
the loop counter that controls iterations of a loop; or repeatedly modified inside 
the loop body. 

The intuitive interpretation of S, U, and R is that if the current state (after 
executing E) is different than the previous state (before executing E), then new 
states are produced in the given loop iteration; otherwise, they are redundant 
and the code R is then responsible for preventing those redundant states to 
be included into the states vector. Note further that the code A assigns non¬ 
deterministic values to all loops variables so that the model checker can explore 
all possible states implicitly. Differently, Grofie et al. El havoc all program 
variables, which makes it difficult to apply their approach to arbitrary programs 
since they do not provide enough information to constrain the havocked variables 
in the program. Similarly, the loop for can easily be converted into the loop while 
as follows: for{B-, c; D) {E; } is rewritten as 


B; while{c) {E; D;} 


( 2 ) 


where B is the initial condition of the loop, c is the halt condition of the loop, 
D is the increment of each iteration over B, and E is the actual code inside 
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the loop for. No further transformations are applied to the loop for during the 
inductive step. Additionally, the loop do while can trivially be converted into 
the loop while with one difference, the code inside the loop must execute at least 
once before the halt condition is checked. 

The inductive step is thus represented by 7Act => cj)^ where 7 is the transition 
relation of P, which represents a loop-free program (cf. Definition Ih after ap¬ 
plying transformations 0 and Q . The intuitive interpretation of the inductive 
step is to prove that, for any un^ding of the program, there is no assignment of 
particular values to the program variables that violates the safety property being 
checked. Finally, the induction hypothesis of the inductive step consists of the 
conjunction between the postconditions {Post) and the termination condition 
(a) of the loop. 


Invariant Generation To infer program invariants, we adopted the PIPS [IB] 
tool, which is an interprocedural source-to-source compiler framework for C and 
Fortran programs and relies on a polyhedral abstraction of program behavior. 
PIPS development has been driven for almost twenty years to automatic analysis 
of large size programs [19]. PIPS performs a two-step analysis: (1) each program 
instruction is associated to an affine transformer, representing its underlying 
transfer function. This is a bottom-up procedure, starting from elementary in¬ 
structions, then working on compound statements and up to function defini¬ 
tions; (2) polyhedral invariants are propagated along with instructions, using 
previously computed transformers. 

In our proposed method, PIPS receives the analyzed program as input and 
then it generates invariants that are given as comments surrounding instruc¬ 
tions in the output C code. These invariants are translated and instrumented 
into the program as assume statements. In particular, we adopt the function 
assume (ea:pr) to limit possible values of the variables that are related to the in¬ 
variants. This step is needed since PIPS generates invariants that are presented 
as mathematical expressions (e.g., 2j < 5t), which are not accepted by C pro¬ 
grams syntax and invariants with ffinit suffix that is used to distinguish the old 
value from the new value. 


2.2 Running Example 

A program extracted from the benchmarks of the SV-COMP m is used as a 
running example as shown in Figure which already includes invariants using 
polyhedral. In Figure]^ a is an integer constant and note that variables i and sn 
are declared with a type larger than the type of the variable n to avoid arithmetic 
overflow. Mathematically, the code above represents the implementation of the 
sum given by the following equation: 


Sn = a, = na, n > 1 


(3) 


In the code of Figure the invariants produced by PIPS are included as as¬ 
sume statements; the property (represented by the assertion in line 131 must 
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1 

int main(int argc , char **argv) 

2 

{ 

3 

long long int i = 1, sn = 0; 

4 

assume) i==l && sn==0 ); // Invariant 

5 

unsigned int n; 

6 

assume (n > = 1 ); 

7 

while (i<=n) { 

8 

assume) l<=i &fe i<=n ); // Invariant 

9 

sn = sn+a; 

10 

i++; 

11 

} 

12 

assume) l<=i && n-|-l<=i ); // Invariant 

13 

assert(sn^=n*a); 

14 

} 


Fig. 3: Running example for the fc-induction algorithm. 


be true for any value of n (i.e., for any unfolding of the program). Differently 
from our fc-induction algorithm, BMC techniques have difficulties in proving the 
correctness of this (simple) program since the upper limit value of the loop, rep¬ 
resented by n, is non-deterministically chosen (i.e., the variable n can assume 
any value from one to the size of the unsigned int type, which varies between 
different types of computers). Due to this condition, the loop will be unfolded 
2" — 1 times (in the worst case, 2^^ — 1 times on 32 bits integer), which is thus 
impractical. Basically, the bounded model checker would symbolically execute 
several times the increment of the variable i and the computation of the variable 
sn by 4, 294,967, 295 times. To solve the problem of unfolding the loop 2" — 1 
times, the translations previously described are performed. 


The Base Case The base case initializes the limits of the loop’s termination 
condition with non-deterministic values so that the model checker can explore 
all possible states implicitly. The pre- and postconditions of the loop shown in 
Figure in static single assignment (SSA) form |T5], are as follows: 

„ ni = nondetjuint A rii > 1 

Asni=0A*i = l 


Post := [*fe > 1 A ifc > ni => suk = ni x a] 

where Pre and Post are the pre- and postconditions to compute the sum given 
by Equation ([^, respectively, and nondetjuint is a non-deterministic function, 
which can return any value of type unsigned int. In the preconditions, ni repre¬ 
sents the first assignment to the variable n, which is a non-deterministic value 
greater than or equal to one. This ensures that the model checker explores all 
possible unwindings of the program. Additionally, sni represents the hrst as¬ 
signment to the variable sn and ii is the initial condition of the loop. In the 
postconditions, suk represents the assignment n -I- I for the variable sn in Fig¬ 
ure]^ which must be true if ik > ni. The code that is not pre- or postcondition is 
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represented by the variable Q (i.e., the sequence of commands inside the loop for) 
and it does not undergo any transformation during the base case. The resulting 
code of the base case transformations can be seen in Figure [^(cf. Definition [^. 
Note that the assume (in line 11), which consists of the termination condition, 
eliminates all execution paths that do not satisfy the constraint i > n. This 
ensures that the base case finds a counterexample of depth k without reporting 
any false negative result. Note further that other assume statements, shown in 
Figure are simply eliminated during the symbolic execution by propagating 
constants and checking that the resulting expression evaluates to true [5]. 


1 

int main(int argc , char **argv) { 

2 

long long int i , sn=0; 

3 

unsigned int n=nondet _uint () ; 

4 

assume (n> = l); 

5 

i=l; 

6 

if (i<=n) { ^ 

7 

sn = sn + a; s k copies 

8 

i++; J 

9 

} 

10 


11 

assume(i>n); // unwinding assumption 

12 

assert( sn^=n*a); 

13 

} 


Fig. 4: Example code for the proof by mathematical induction, during base case. 


The Forward Condition In the forward condition, the ^-induction algorithm 
attempts to prove that the loop is sufficiently unfolded and whether the property 
is valid in all states reachable within k steps. The postconditions of the loop 
shown in Figure]^ in SSA form, can then be defined as follows: 

Post := [ifc > ni A sn^ = rii x a] 

The preconditions of the forward condition are identical to the base case. 
In the postconditions Post, there is an assertion to check whether the loop is 
sufficiently expanded, represented by the constraint ik > ni, where ik represents 
the value of the variable i at iteration n + 1. The resulting code of the forward 
condition transformations can be seen in Figure|^(cf. Definitionjl ). The forward 
condition attempts to prove that the loop is unfolded deep enou^ (by checking 
the loop invariant in line 11) and if the property is valid in all states reachable 
within k iterations (by checking the assertion in line 12). As in the base case, 
we also eliminate assume expressions by checking whether they evaluate to true 
by propagating constants during symbolic execution. 


The Inductive Step In the inductive step, the fc-induction algorithm attempts 
to prove that, if the property is valid up to depth fc, the same must be valid for 
the next value of k. Several changes are performed in the original code during this 
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1 

int main(int argc , char **argv) { 

2 

long long int i , sn=0; 

3 

unsigned int n=nondet _uint () ; 

4 

assume (n> = l); 

5 

i=l; 

6 

if (i<=n) { ^ 

7 

sn = sn -I- a ; s k copies 

8 

i++; J 

9 

} 

10 


11 

assert(i>n); // check loop invariant 

12 

assert ( sn^=n*a) ; 

13 

} 


Fig. 5: Example code for the proof by mathematical induction, during forward 
condition. 


step. First, a structure called statet is defined, containing all variables within the 
loop and the halt condition of that loop. Then, a variable of type statet called 
cs (current state) is declared, which is responsible for storing the values of a 
given variable in a given iteration; in the current implementation, the cs data 
structure does not handle heap-allocated objects. A state vector of size equal to 
the number of iterations of the loop is also declared, called sv (state vector) that 
will store the values of all variables on each iteration of the loop. 

Before starting the loop, all loops variables (cf. Definitions and are 
initialized to non-deterministic values and stored in the state vector on the first 
iteration of the loop so that the model checker can explore all possible states 
implicitly. Within the loop, after storing the current state and executing the 
code inside the loop, all state variables are updated with the current values of 
the current iteration. An assume instruction is inserted with the condition that 
the current state is different from the previous one, to prevent redundant states 
to be inserted into the state vector; in this case, we compare svj [f] to csj for 
0 < j < k and 0 < * < fc. In the example we add constraints as follows: 

svi [0] ^ csi 

SUl [0] ^ CSi A SU2 [1] CS2 

sui [0] ^ csi A svi [1] 7^ CS2 A ... svk [f] ^ csk 

Although, we can compare svk [*] to all cSk for i < k (since inequalities are 
not transitive), the number of constraints can still grow very large quickly, and 
easily “blow-up” the SMT solver. In the SV-COMP benchmarks, we observed a 
substantial improvement in performance if we generate and check constraints as 
described in Equation Q. 

Finally, an assume instruction is inserted after the loop, which is similar to 
that inserted in the base case. The pre- and postconditions of the loop shown in 
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Figure in SSA form, are defined as follows: 


Pre 


ni = nondet-uint A ni > 1 
A sni = 0 A = 1 
A csi-Vo = nondetjuint 

A ... 

A csi-Vm = nondetjuint 


Post := [ik > TT-i => suk = nxfl] 

In the preconditions Pre, in addition to the initialization of the variables, 
the value of all variables contained in the current state cs must be assigned 
with non-deterministic values, where m is the number of (automatic and static) 
variables that are used in the program. The postconditions do not change, as 
in the base case; they only contain the property that the algorithm is trying to 
prove. In the instruction set Q, changes are made in the code to save the value 
of the variables before and after the current iteration i, as follows: 


Q:= 


— 1] = cSi A S' 
A cs^.vo = vo^ 

A ... 

A CSi.VjYi = Vjni 


In the instruction set Q, s?;[i — 1] is the vector position to save the current 
state csi, S is the actual code inside the loop, and the assignments csi.vo = 
voi A ... A cSi.Vm = Vmi represent the value of the variables in iteration i being 
saved in the current state csi. The modified code for the inductive step, using 
the notation defined in Section can be seen in Figure Note that the if- 
statement (lines 18-26) in Figure [6 is copied /c-times according to Definition 
As in the base case, the inductive step also inserts an assume instruction, whi3i 
contains the termination condition. Differently from base case, the inductive step 
proves that the property, specified by the assertion, is valid for any value of n. 

Lemma 1 If the induction hypothesis {Post A (i < n)} holds for A: -I- 1 
consecutive iterations, then it also holds for k preceding iterations. 

After the loop while is finished, the induction hypothesis {Post A —•{i<n)} 
is satisfied on any number of iterations; in particular, the SMT solver can easily 
verify Lemma and conclude that sn == n * a is inductive relative to n. As in 
previous cases, we also eliminate assume expressions by checking whether they 
evaluate to true by propagating constants during symbolic execution. 


3 Experimental Evaluation 

To evaluate the proposed method, we initially adopted the benchmarks of the 
SV-COMP 201^ in particular the Loops subcategory. The fc-induction algo¬ 
rithm was implemented in two different ways, with and without invariants us¬ 
ing polyhedral. The implementation of the algorithm with invariants is called 

http://sv-comp.sosy-lab.org/2015/ 
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//variables inside the loop 

typedef struct state { 
long long int i , sn; 
unsigned int n; 

} statet; 

int main (int argc , char **argv) { 
long long int i , sn=0; 
unsigned int n=nondet _uint (); 
assume (n> = l); 
i=l; 

//declaration of current state 
//and state vector 
statet cs, sv[n]; 

//A: assign non— deter minis tc values 
cs . i=nondet _uint (); 
cs . sn=nondet _uint (); 
c s . n=n ; 

if (i<=n) { //c: halt condition 
sv[i—l] = cs; //S: store current state 
sn = sn + a; //E: code inside the loop 
//U: update variables with local values 
cs . i=i ; cs . sn=sn ; cs . n=n ; 

//R: remove redundant states 

assume (sv[i—l]! = cs); 

i++; 

} 

assume(i>n); //unwinding assumption 
assert(sn^=n*a); 


Fig. 6: Example code for the proof by mathematical induction, during inductive 
step. 


DepthKjf] The ESBMC vl.24.1 was adopted in both implementation. This way, 
we performed a comparison between DepthK (i.e., fc-induction and invariants), 
ESBMC with fc-induction, and ESBMC with plain BMC. 

3.1 Experimental Setup 

The experiments were conducted on a computer with Intel Core 17-2600, 3.40GHz 
with 24GB of RAM with Ubuntu 14.04.1 LTS 64-bit. Each verification task is 
limited to a CPU run time of 15 min and a memory consumption of 15 GB. 
Additionally, we defined the maxJterations to 100 (cf. Fig.[^. 

Loops subcategory consists of 142 verification tasks, which are organized as 
follows: 49 benchmarks contain valid properties (i.e., the verification tool must 
be able to prove correctness) and 93 benchmarks contain invalid properties (i.e., 
the verification tool must be able to falsify the property). 

^ https://github.com/hbgit/depthk 




12 


Herbert Rocha, Hussama Ismail, Lucas Cordeiro, and Raimundo Barreto 


3.2 Experimental Results 

We evaluate the experimental results as follows: we adopt the same score scheme 
that is used by the SVCOMP rule^ in particular, we check the verification result 
and time presented by each implementation. Figure shows the comparative 
results between the scores generated by DepthK with fc-induction and invariants 
using polyhedral, ESBMC using k-induction only, and ESBMC using plain BMC. 
The total scores in the Loops subcategory for ESBMC with plain BMC is 66; 
ESBMC using k-induction only is 115; and DepthK combining fc-induction and 
invariants is 141. 
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Fig. 8: Verification results 


Figure shows the distribution of the result by each step of the A:-induction 
algorithm (i.e., base case, forward condition, and inductive step), including ver¬ 
ifications that result in unknown and timeout. If we analyze the distribution of 
the results, we identified that DepthK was able to prove properties during the 
forward condition in 6% of the verification tasks, and ESBMC with A:-induction 
proves properties only during the inductive step. As a result, we observe that 
invariants help prove that the loop is sufficiently unfolded and whether the prop¬ 
erty is valid, taking into account that this is performed in the forward condition 
step. DepthK has not found a solution in 28% of the verification tasks; this 
is explained by the invariants generated from PIPS, which could not generate 
strong invariants to be k-inductive either due to the transformers or due to the 

http://sv-comp.sosy-lab.org/2015/rules.php 
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invariants are not convex. ESBMC with fc-induction does not find a solution in 
37% of the verification tasks, therefore providing evidences that invariants can 
improve the verification results. DepthK and ESBMC with fc-induction found a 
solution in 66% and 53% of the verification tasks, respectively. However, they 
reported 6% and 10% of timeouts, respectively. 

Analyzing the verification time, we identified that ESBMC with fc-induction 
verified all benchmarks in 15320 seconds; DepthK took approximately 11518 
seconds, i.e., a reduction of 25% of the verification time; and ESBMC using 
plain BMC took about 3100 seconds (but solves less verification tasks). 

4 Related Work 

The application of the fc-induction method is gaining popularity in the soft¬ 
ware verification community. Recently, Bradley et al. introduce “property-based 
reachability” (or IC3) procedure for the safety verification of systems |22l23j . 
The authors have shown that IC3 can scale on certain benchmarks where fc- 
induction fails to succeed. However, we do not compare fc-induction against IC3 
since it is already done by Bradley [H]; we focus our comparison on related 
fc-induction procedures. 

Previous work on the one hand have explored proofs by mathematical in¬ 
duction of hardware and software systems with some limitations, e.g., requiring 
changes in the code to introduce loop invariants mm- This complicates the 
automation of the verification process, unless other methods are used in combina¬ 
tion to automatically compute the loop invariant Similar to the approach 

proposed by Hagen and Tinelli m, our method is completely automatic and 
does not require the user to provide loops invariants as the final assertions after 
each loop. On the other hand, state-of-the-art BMC tools have been widely used, 
but as bug-finding tools since they typically analyze bounded program runs EH; 
completeness can only be ensured if the BMC tools know an upper bound on 
the depth of the state space, which is not generally the case. This paper closes 
this gap, providing clear evidence that the fc-induction algorithm can be applied 
to a broader range of C programs without manual intervention. 

Grofie et al. describe a method to prove properties of TLM designs (Trans¬ 
action Level Modeling) in SystemC [13]. The approach consists of converting 
a SystemC program into a C program, and then it performs the proof of the 
properties by mathematical induction using the CBMC tool [3]. The difference 
to the one described in this paper lies on the transformations carried out in 
the forward condition. During the forward condition, transformations similar to 
those inserted during the inductive step in our approach, are introduced in the 
code to check whether there is a path between an initial state and the current 
state fc; while the algorithm proposed in this paper, an assertion is inserted at 
the end of the loop to verify that all states are reached in fc steps. 

Donaldson et al. describe a verification tool called Scratch |7] to detect data 
races during Direct Memory Access (DMA) in the CELL BE processor from 
IBM |7]. The approach used to verify C programs is the fc-induction technique. 
The approach was implemented in the Scratch tool that uses two steps, the base 
case and the inductive step. The tool is able to prove the absence of data races, 
but it is restricted to verify that specific class of problems for a particular type 
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of hardware. The steps of the algorithm are similar to the one proposed in this 
paper, but it requires annotations in the code to introduce loops invariants. 

Kahsai et al. describe PKIND, a parallel version of the tool KIND, used 
to verify invariant properties of programs written in Lustre |24j . In order to 
verify a Lustre program, PKIND starts three processes, one for base case, one 
for inductive step, and one for invariant generation, note that unlike ESBMC, 
the k-induction algorithm used by PKIND does not have a forward condition 
step. The base case starts the verification with fc = 0, and increments its value 
until it finds a counterexample or it receives a message from the inductive step 
process that a solution was found. Similarly, the inductive step increases the 
value of k until it receives a message from the base case process or a solution is 
found. The invariant generation process generates a set of candidates invariants 
from predefined templates and constantly feeds the inductive step process, as 
done recently by Beyer et al. [25] (we do not compare to Beyer et al. since their 
technical report appeared only after we submitted our CAV abstract and thus 
there was no time to further evaluate their work). 

5 Conclusions 

The main contributions of this work are the design, implementation, and eval¬ 
uation of the fc-induction algorithm adopting invariants using polyhedral in a 
verihcation tool, as well as, the use of the technique for the automated verifi¬ 
cation of reachability properties in heteregenous programs. To the best of our 
knowledge, this paper marks the first application of the fc-induction algorithm 
to a broader range of C programs with loops. To validate the fc-induction algo¬ 
rithm, experiments were performed involving 142 benchmarks of the SV-COMP 
2015 loops subcategory. The experimental results also show that the fc-induction 
algorithm without invariants was able to verify 52% of the benchmarks in 15320 
seconds, and fc-induction algorithm with invariants using polyhedral was able 
to verify 66% of the benchmarks in 11518 seconds, which gives a speedup of 
roughly 25% faster than the fc-induction algorithm without the invariants ver¬ 
sion. Given a fixed timeout, this speedup can also improve the quality of the 
results (around 13%), because more programs can be verified if their verifica¬ 
tion would otherwise be interrupted by the time limit. In addition, both forms 
were able to prove or falsify a wide variety of safety properties; however, the 
fc-induction algorithm adopting polyhedral solves more verihcation tasks, which 
demonstrate an improvement of the induction algorithm effectiveness. 
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